OpenEdge Getting Started:<br />Core Business Services Implementing additional auditing options

Auditing has a number of options that you, the application developer, can choose to implement in your 4GL product. If you implement changes in your application, those options will be available at the production site. If you do not implement the changes, the production site will not have this auditing optional feature. This section lists those development-time options.

If your auditing needs are nonexistent or the OpenEdge database’s record auditing is all that is necessary (with no execution context, and if the user who connected to the database is the user to record in the audit log), you do not need to enable auditing for your application.

The database’s record provides the following support, without you making any application changes:

Support of CREATE, UPDATE, and DELETE record operations.

Support for identifying which record was affected.

Support for identifying which record fields were affected.

Support for recording field values at the time the record operation took place.

Identifying which database transaction the record operation was part of.

Identifying which sequence record operations occurred within the transaction.

The date, time, and time zone of the record operation.

The user who made the change, provided the user is either the blank user or the one whose account is in the OpenEdge database’s _User table, and that account was authenticated through startup/connect -U and -P options and/or the Progress 4GL SETUSERID function to the _User table.

If you do not make application changes to support auditing, you will not have any application execution context available to know which application performed the record operation (SQL/Progress 4GL), who the user was (if the Progress 4GL application uses its own user accounts), or any other details about the environment in which the record operation was performed.

Supplying OpenEdge application context information

By modifying your application to include application context, you can attach to the audit records information such as:

Which application was involved — This information is necessary if your product has multiple execution components or your product will be part of a partnership with other Progress Software Corporation application vendors.

Checkpoint locations within the application’s execution — The checkpoint locations identify the origin of a record operation.

Supporting user accounts outside of the _User table

If you do not want to support populating the _User table with all of your application’s user accounts and authenticating the application as one of those users, you must perform the following changes:

If necessary, change your database connection process to one of the following:

The blank user (with blank user access denied to all).

A single default user account, which is used by all application connections, in the _User table.

These user IDs can remain for the lifetime of the Progress session or can be replaced by an external user account ID as soon as the connection is made.

Refer to Chapter 4, "Identity Management," for information about establishing an OpenEdge application’s current user ID.

Using a dedicated OpenEdge database for auditing

You can store application event data in any audit-enabled database on which the event is enabled. You can use a single storage location or a combination of storage locations; you can also connect directly to a long-term storage area, which eliminates the need to perform the archive step in storing the data.

Setting up READ auditing

If your application auditing requires knowing when certain records are read and presented to a user, you must change your application to:

Define an application-defined READ audit event in the _aud-event table. (Choose an event equal to or greater than 32000.)

Define the data formats for the audit record’s context (indexed) and detail fields. The context field format can be used to index on and find records for reporting. It is recommended that you mimic the OpenEdge database event default field value recording, which streams the field values.

Add code to your application where the record read operations occur, and execute the LOG-AUDIT-EVENT method (for the AUDIT-CONTROL system handle) to record the application-defined event.

For more information about the method and handle, see OpenEdge Development: Progress 4GL Reference .

Create a .ad file to go with your application’s deployment to load the _aud-event table definitions you have made into the production database instance.

Using a custom audit data/policy archive tool

There are a number of reasons to write your own OpenEdge archival tool. You might want to do this to:

Import audit data collected in an older, external system.

Add extra filters to allow more selectivity regarding which audit records are moved or destroyed.

When you write such a tool, you have to be very careful, and you might have to certify your archive tool to government auditors. The key to the archival process is that it requires an authenticated user to have the audit data archiver privilege. Only then will the OpenEdge application have CREATE and DELETE record access to the auditing data tables.

Bootstrapping the audit administrator user

To get auditing running, you must set up security, deciding if you are going to have a separation of duty as far as auditing privileges are concerned. Will the security and database administrators manage auditing, or should it be a separate task?

If the database administrators are handling the auditing tasks, the DBAs will want to grant themselves audit data archiver privileges. If the DBAs are not handling auditing and they want to abdicate responsibility to a primary and a secondary audit administrator, those audit administrators can set up the audit reader and audit data archiver permissions for other users.

It is recommended that you have an audit data archiver account separate from the audit administrator account. The audit data archiver privilege can prove potentially dangerous if entrusted to the wrong hands, as the audit data archiver can delete records or create misleading records, thereby creating refutable data.

Creating audit policy and report templates

Your database application will have many databases, tables, and fields. Without specific knowledge of the schema, the production site will not be able to create auditing policies and run reports. As the developer, you have the knowledge of the schema and can provide audit policy templates and report queries to the production site. This goes along with the schema’s documentation. The production site can then copy, customize, and activate the templates with far less work and ramp-up time.

One thing you do not want to do is turn everything on to be audited and then let the production site report only on events of their choosing. Such an approach would likely consume much storage space and increase greatly the run-time overhead. If you know for certain that specific events do not need to be audited, be sure not to identify them as audit events.

The same situation applies to report queries. From templates, the production site can do less work and be running faster if it can take advantage of the developer’s knowledge.

Supporting custom audit policy tools

When a large, complex application is involved, it can be impractical to expect a production site to manage audit policies for the application’s many tables across multiple databases. In such a situation, the developer can customize the audit policy tool by applying knowledge of the application and database schemas to the user interface of the customized policy tool based on shared Progress procedures, thereby greatly simplifying the audit policy configuration and maintenance.

For example, you can create a policy in segments with one segment holding a common configuration for a type of report or reports. The production site can then turn on the segment.